Revert "tests: use RUNPATH instead of RPATH consistently (#309)" #323
Conversation
…#309)" This reverts commit eeb5e45. Said change did not undergo standard review and seems superfluous, since we inject neither RPATH nor RUNPATH into the resulting shared library, therefore it's questionable why we should be carrying this burden and influence anything by force. Redistributors are free to make their own choices. If that requires assistance on libqb's side, their _conditional_ patches are welcome. Signed-off-by: Jan Pokorný <[email protected]>
|
nack. |
|
Also:
|
|
NACK. I'm not reverting a change just because you didn't get to review it. |
|
Misunderstanding emerges. I am all for retaining that provided that the reason is properly justified. Can you answer these simple questions, please, so we may go forward?
Please, enlighten me, which configuration in particular is troubling to |
|
On 9/17/18 2:39 PM, Jan Pokorný wrote:
Misunderstanding emerges.
I am all for retaining that provided that the reason is properly justified.
It is written in the original commit.
assume you have libqb installed on the system (via whatever package
manager) and you run the test suite:
1) WITHOUT this commit, the test binaries will use the installed libqb
and not the currently built one
2) WITH this commit, the test binaries will use the newly built libqb in
the source tree as expected.
So far, it appears just as an additional complexity not paralleled
elsewhere.
The main purpose is to remove the entangled obscurity with said commit,
something not very helpful for an open source project.
Can you answer these simple questions, please, so we may go forward?
1.
Does kronosnet test suite use system-wide |libqb| or does it consume it
internally as an subproject, via |libtool| depending on its |*.la|
files etc.?
Completely irrelevant. This commit to libqb is a port of a similar fix
for knet.
2.
Does kronosnet test suite require |libqb| compiled with any sort of
dynamic linker search path overrides (|*RPATH|, |*RUNPATH|)?
knet doesn't require libqb for anything but generating documentation.
3.
Is there are any actual risk |libqb| would taint intended separation by
being used to load any libraries transitively -- this is the only
case I can
imagine would need this rectification.
Nope, because knet does not use and will not use libqb.
Please, enlighten me, which configuration in particular is troubling to
the extent said commit is necessary. Thank you.
Your *own* test suite.
Fabio
…
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#323 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAW6rdP-CMGAww1fYq4c96U3e_yXyOErks5ub5frgaJpZM4WplOH>.
|
Ah, I start to see, I really wish the initial problem statement was So does it mean that: a. b. ...which Or is the reproducing scenario different? |
|
On 9/17/18 3:25 PM, Jan Pokorný wrote:
Please, enlighten me, which configuration in particular is
troubling to
the extent said commit is necessary. Thank you.
Your /own/ test suite.
Ah, I start to see, I really wish the initial problem statement was
less obfuscated (which is one of the purposes for patch review).
So does it mean that:
a. |libtool| on some systems (Debian?) will compile test suite binaries
with |RPATH| unconditionally and automatically...
All systems but Fedora and RHEL use RUNPATH by default (maybe FreeBSD).
b. ...which |libtool|'s wrapper scripts for these binaries will try to
override then with |LD_LIBRARY_PATH=...| definition, which will fall
short to achieve the override (as only |RUNPATH| can be overridden?)
Correct.
Or is the reproducing scenario different?
That's correct.
…
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#323 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAW6rcIOzbldW4LrhM0ORXo2SLhV6ognks5ub6LJgaJpZM4WplOH>.
|
This reverts commit eeb5e45.
Said change did not undergo standard review and seems superfluous,
since we inject neither RPATH nor RUNPATH into the resulting shared
library, therefore it's questionable why we should be carrying this
burden and influence anything by force. Redistributors are free to
make their own choices. If that requires assistance on libqb's side,
their conditional patches are welcome.
Signed-off-by: Jan Pokorný [email protected]